An Ethernet ring 15 is a collection of ring nodes forming a closed loop whereby each ring node is connected to two adjacent ring nodes via duplex communication links 16. FIG. 1 illustrates an Ethernet ring 15 comprising 6 ring nodes connected to adjacent ring nodes via duplex communication links 16.
A loop of data in the Ethernet ring 15 consumes a lot of resources in the Ethernet ring 15 and is therefore an undesired condition. There is therefore a need for protection against loops in the Ethernet ring 15. The topology of an Ethernet Ring Protection, ERP, network can be a single Ethernet ring or a collection of interconnected Ethernet rings.
The G.8032 protocol is designed for Ethernet ring topologies and is developed as a standardized alternative to replace the spanning tree protocol, xSTP. It assumes standard 802.1 Q bridges are used and standard 802.3 MAC frames go around the Ethernet ring. G.8032 Ethernet ring nodes support standard FDB MAC learning, forwarding, flush behavior and port blocking/unblocking mechanisms.
The principle of loop prevention within the Ethernet ring 15 is to block one of the ring links 16, either a pre-determined link or a failed link. For example, in a normal state, where there is no link failure as in FIG. 1, one of the ring links 16 is designated as a Ring Protection Link, RPL, 90. The RPL 90 blocks Ethernet traffic to avoid traffic looping. An RPL blocking is provided by port blocking at both end of the RPL 90. One of the nodes is called RPL Owner Node, e.g. ring node E 95, which is also responsible for activating reversion behavior from protected or Manual Switching or Forced Switching conditions. The other node is called RPL Node, e.g. ring node D 97, which is not responsible for activating reversion behavior. In G.8032 version 1, one end of RPL is blocked for breaking the loop in the normal state. In the draft of G.8032 version 2, both ends of RPL are blocked in a normal state to avoid unnecessary flooding.
FIG. 2 illustrates an Ethernet Ring Protection, ERP, state. When a link failure occurs, for example, a link 200 between Node A 210 and Node B 220. Node A 210 and Node B 220 block ports 211, 212 for the failed link 200 and send a R-APS, Ring-APS, Signal Failure messages to indicate the link failure. The Signal Failure messages are circulated around the Ethernet ring through a Ring APS channel (not shown). When the RPL Owner Node E 230 and RPL Node D 240 receive this message, they unblock ports to RPL.
When a link failure is restored, for example, if the link failure between Node A 210 and Node B 220 in FIG. 2 disappears, then Node A 210 and Node B 220 keep port 211 and port 212 blocked and send out R-APS No Failure message. The messages are circulated around the ring through Ring APS channel. When the RPL Owner Node E 230 and RPL Node D 240 receive this message, they block the ports to RPL and send out R-APS Blocking messages. Node A 210 and Node B 220 unblock the port 211 and 212 when they receive the R-APS Blocking messages from Node E 230 and Node D 240. Now the ERP ring is back to the Normal State.
FIG. 3 illustrates an example of a multi-ring/ladder network 300 comprising two Ethernet rings 310, 320. The G.8032 standard also supports the multi-ring/ladder network 300 illustrated in FIG. 3.
If the multi-ring/ladder network 300 is in its normal condition, RPL Owner Node and RPL node of each ring block the transmission and reception of traffic over the RPL for that ring. In this example, RPL Owner Node for ERP 1 is H 330 and for ERP 2 is E 340.
FIG. 4 illustrates a multi-ring/ladder network 400 in which a superloop 410 can be created. A superloop 410 is formed when a shared link failure occurs. For example in FIG. 4, if a link 425 between Node A 420 and Node B 430 fails, as this link 425 belongs to both ring 1 440 and ring 2 450, both rings 440, 450 initiate protection and unblock ports to RPL. A superloop 410 is formed. We therefore need a special protection mechanism for multi-ring/ladder network 400 to avoid the superloop problem.
FIG. 5 illustrates a Multi-ring/ladder network 500 with protection against a superloop. The superloop problem is solved by creating sub-rings. For example in Figure, ERP 1 510 is composed of nodes A, B, I, H and G and all links therein between. ERP 2 520 is composed of nodes A, B, C, D, E and F and all links except a link 530 between A and B. The link 530 between A and B only belongs to ERP 1 510. If the link 530 between A and B fails, only ERP1 510 will respond and ERP 2 520 will do nothing. ERP 2 520 is a sub-ring as defined in G.8032, which transmits R-APS message on the R-APS virtual channel.
A metro network is a network that covers a metropolitan area. The metro network is often based on the Ethernet standard. The metro network is commonly used as a metropolitan access network to connect subscribers and businesses to a larger service network or the Internet. In the metro network deployment, there may be a requirement to use G.8032 in an aggregation network and Virtual private LAN service, VPLS, in a core network.
FIG. 6 illustrates interworking between Provider edge, PE, routers 601, 602 and an Ethernet ring 603 running G.8032. The motivation of integrating Provider Edge routers 601, 602 into Ethernet ring 603 is to provide interface protection.
For PE1 601 and PE2 602 shown in FIG. 6, an interface (not shown) facing the Ethernet ring may be G.8032 ring ports. There is a dedicated tunnel (not shown) between PE1 601 and PE2 602. The G.8032 ring control messages received on the ring ports of PE1 601 or PE2 602 are transmitted transparently through the tunnel back to the Ethernet ring 603. No local ring control messages are leaked to a core network 613. No link level CCMs are sent through the tunnel between PE1 and PE2.
There are at least 3 interface failure scenarios:
1. Link Failure Between G.8032 Ring Bridge and One of the PEs 601, 602
For example, a link 604 between the Ring Bridge 605 and PE2 602 fails as shown FIG. 7. In this scenario, PE2 602 does nothing. The adjacent ring bridge 605 initiates Ethernet ring protection after detecting the link failure by unblocking RPL 606.
2. Tunnel Failure Between PE Nodes
For example, a tunnel 607 between PE1 601 and PE2 602 fails as in FIG. 8. PE1 601 and PE2 602 know it is a tunnel failure when they do not receive IGP withdrawal of partner edge router PE1 601, PE2 602 after certain amount of time. Any PE node 601, 602, 608, 609 will send a withdrawal message to other PE nodes 601, 602, 608, 609 if it finds out another PE node 601, 602, 608, 609 does not exist. After this period, PE1 601 and PE2 602 stop sending CCM from their ring interface towards ring bridges. The adjacent ring bridges 610, 611 detect there is a failure and initiate ring protection by unblocking RPL 612.
3. PE Node Failure
For example, the node of PE2 602 fails as in FIG. 9. The adjacent ring bridge 611 initiates ring protection after detecting the failure, e.g. no CCMs. PE1 601 know it is a node failure when it receives IGP withdrawal message of PE2 602 from PE4 609. PE1 601 then also sends out SF, signal failure, message to adjacent ring bridge 610 to inform of this failure. When ring bridges receive these messages, the RPL 612 will be unblocked to provide protection.
FIG. 10 illustrates a case where the core network 110 is segmented. In FIG. 10 the core network 110 is segmented into two portions 110a and 110b. In a case where the core network 110 is segmented a superloop 116 can be created if the existing mechanisms for protection against loops are used. In FIG. 10 the core network 110 is segmented into two parts 110a, 110b and there is therefore no communication between PE1 601, PE2 602 and PE3 608, PE4 609, respectively.
Since the core network is segmented into two parts 110a, 110b, PE1 601 is only connected to PE3 608 and PE2 602 is only connected to PE4 609. There is no communication between PE1 601, PE3 608 and PE2 602, PE4 609. PE1 601 will send out withdrawal messages about PE2 602 and PE4 609. PE2 602 will send out withdrawal messages about PE1 601 and PE3 608. PE3 608 will send out withdrawal messages about PE2 602 and PE4 609. PE4 609 will send out withdrawal messages about PE1 601 and PE3 608. After receiving those withdrawal messages, PE1 601 will assume PE2 602 has a node failure, at the same time, PE2 602 will assume PE1 601 has a node failure. Both PE1 601 and PE2 602 will send out SF message to adjacent ring bridges 125 to initiate the ring protection by unblocking RPL 160. PE3 608 and PE4 609 will behave the same way to unblock RPL 127 to provide protection. The result will be a superloop 116 as shown in FIG. 10.
There is therefore a need for an improved solution for increasing the robustness of Ethernet rings by preventing that superloops can be created, which solution solves or at least mitigates at least one of the above mentioned problems.